In computer systems that employ distributed networks where database information is frequently transferred, there exists the need to maintain both forward and backwards compatibility among the various software releases generated during a systems lifetime. Examples of computer systems utilizing distributed networks are Local Area Networks (LANs) and Wide Area Networks (WANs). In these computing environments, forward compatibility describes the relationship between a progression of software releases, whereby installation of a new software release does not compromise the fitness, form, or function achieved under previous software versions. In essence, the new software performs like the old, despite the inclusion of additional features. Backwards compatibility is achieved when the reinstallation of a previous software version does not render the system inoperable.
This same need arises in computer systems that employ redundant database information which is either compared or exchanged. One such example is a telephony computer designed to perform the switching of customer calls. An example is the Motorola Electronic Mobile Exchange (EMX) family of cellular switches. These include the Motorola EMX 100, 250, 500, and 2500 switch families which support cellular radiotelephone services in several major metropolitan markets. The interested party may receive full system/hardware descriptions on such devices by contacting Motorola's Cellular Publishing Services at 1501 W. Shure Drive Shure Drive, Arlington Heights, Ill. 60004 and requesting Instruction Manuals 68P8105196E-99E, 68P81052E-54E and 68P81056E for the EMX 100-500 Family of Switches or Instruction Manuel 68P09201A07-A for the EMX2500 electronic switch all of which are incorporated herein by reference.
Simply stated, a telephony computer is nothing more than a large switch that employs sophisticated software capable of managing and directing multiple customer calls per second. In this effort, it is necessary to develop a comprehensive customer database capable of reporting the various telephone subscribers, their individual accounts, and various service features. Presently, most of the customer database information is of a static nature; not subject to frequent change and therefore suitable for storage in backup form. With the expansion of customized telephone services, however, a growing portion of the database information is dynamic.
Unlike static, dynamic information is customer generated, subject to certain alteration, and therefore totally unsuitable for hard copy storage. Typical examples of dynamic information include the programmable automatic redial, call forwarding, busy transfer, no answer transfer, or voice mailbox telephone options. While this personalized information is not maintained in hard copy form, it is extremely valuable to the average system subscriber and therefore must be jealously safeguarded during database transfers if quality phone service is to be provided.
In this effort to insure quality service, EMX computers employ a redundant or secondary switch that is a duplication of the primary switch, and capable of continuing service if the primary is ever disabled. During normal operation, the primary and secondary customer databases are frequently compared. These subscriber audits are performed in order to assure primary and secondary database equivalence. In addition, it is quite common for telephony computers to perform subscriber file transfers, wherein the subscriber information residing in one computer is transferred to a different computer. Another frequently performed operation is subscriber feature preservation. This is the process whereby dynamic database information is updated and transferred to the secondary switch the instant the primary becomes disabled. In each of these operations, the existence of forward and backwards compatibility is imperative in order to assure the proper handling and transfer of the appropriate database records. This is especially true for the transfer of dynamic information which is constantly changing and for which there is no hard copy backup.
Forward and backwards compatibility is normally achieved on an individual software release basis. It will be appreciated by those skilled in the art that a typical software update may include the correction of an old software version or the addition of new system features. Each enhancement, however, requires altering the database records supporting the capture of the obsolete or newly acquired information. Such changes present a considerable challenge to the programmer attempting to implement forward and backwards compatibility, because communication between differing database structures may result in the loss of important information. In the telephone business, lost information represents an intolerable breach in the quality of service.
For example, assume an original software release version 1.0 is supported by customer database #1, which contains several records each having elements A, B, and C. The updated release of this software is version 2.0 which is supported by customer database #2. Database #2 also contains several records, however, these records contain elements A, B, and D. During the forward transfer of database #1 information into database #2, it is understood that the software associated with database #2 will disregard the information found in element C. Likewise, during the backwards transfer of database #2 information into database #1, the software associated with database #1 will not comprehend the information found in element D. Ultimately, this unrecognized data must be discarded by the software. Of note, the greater the difference between the subject databases and the more software releases to be encountered, the more complicated system software must be in order handle these inconsistencies and maintain compatibility.
Previous approaches suggest downloading the entire existing database, undesired records and all, and relying upon complex conversion programs capable of converting the original database to a format capable of being passed to the new database. While these programs are entirely capable of discarding obsolete records or ignoring the presence of new records, compatibility will remain a serious problem as the number of operating software releases escalates. Each new release must maintain compatibility with its predecessors, while the predecessors must often be updated in order to successfully communicate with newer releases. This represents a formidable task which is virtually impossible of being fault tolerant.
In order to avoid the needless waste associated with sending unused information across transmission lines of limited capacity, the prior art also suggests manually enter the appropriate database information. Due to the sheer size of some databases, however, manual entry depicts a labor intensive process which is extremely prone to operator error, and incapable of handling the real time demands imposed by dynamic database information.
It would therefore be extremely advantageous to provide a simplistic method for transferring database information between various processors having different database information or structures, while maintaining forward and backwards compatibility.